Using current OTel eBPF profiler against this PR results in stacktraces that looks like this:

From the mix of order of frames, we can tell that this is not a correct representation of a stacktrace.

Hi @florianl, thank you for checking. It does not look good indeed, do you see the mistake in my reasoning though? That's how I interpret the spec, and I think @rockdaboot agrees.

There's some discussion about this in open-telemetry/opentelemetry-ebpf-profiler#534, maybe the two things are related.

I suggest to do things in this order:

1. Make sure that ebpf-profiler has appropriate unit tests that prove that it generates the locations correctly. Create these tests if they are missing.
2. Add proper unit tests to prove that devfiler handles the locations correctly. Eventually fix the code.

If done correctly, receiving and displaying the traces should just work.

Closing this PR as the bug originates the source and will be fixed with open-telemetry/opentelemetry-ebpf-profiler#538.

@florianl are you sure about this? I think the proposed diff is still relevant, even after the fix in ebpf-profiler.

Yes, as investigations like #27 (comment) showed, the bug remains in the source rather than the backend.

As far as I understand the code here, there are two bugs. One was in ebpf-profiler and the other one is still in devfiler, which doesn't take the second indirection into account.

@fandreuz I reopened this PR as this is still an issue, devfiler currently assumes that locations are stored in a linear way (non-deduplicated) and breaks if that's not the case which is also a protocol violation.

The work I did in this PR to enable Location deduplication exposes this breakage in devfiler, your PR seems to fix it. Please test against my fix and we can hopefully get this merged.

Hi @christos68k, thanks for reopening this. I'm on holiday and won't be able to work on this issue before next week. If it's urgent someone else will have to pick it up, I'll be happy to do it later though.

Hi @christos68k, thanks for reopening this. I'm on holiday and won't be able to work on this issue before next week. If it's urgent someone else will have to pick it up, I'll be happy to do it later though.

No worries, I tested it and it works fine for me but feel free to also take a look when you come back.

Asking again, can we also have unit tests with this PR, please?

Hi @rockdaboot, happy to add some tests to this PR. However, I don't see any unit test in this project (find src/ -name "*test*" gave no results). Am I missing something? If not, could you suggest what structure you'd like to use? As far as I know, there's not a unique way to structure unit tests in Rust.

Hi @rockdaboot, happy to add some tests to this PR. However, I don't see any unit test in this project (find src/ -name "*test*" gave no results). Am I missing something? If not, could you suggest what structure you'd like to use? As far as I know, there's not a unique way to structure unit tests in Rust.

Tbh, I am not a rust expert, but would assume doing tests like at

Just for the background:
So far, testing wasn't an issue in this project, as it was an internal tool for developers.
Now that the project is open source, tests become more important as they give confidence to contributors and help with maintaining / reviewing changes.

To enable test runs after the Nix build (and thus also in CI), you should just need to flip the boolean here:

If that doesn't work, just lmk and I'd be happy to take a look.

Merging this PR as it affects multiple people. Tests still can be added in a separate PR.

Thanks @fandreuz for identifying and fixing the issue 🙏